home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1173 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.6 KB
  1. Path: fido.asd.sgi.com!austern
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.programming.threads,comp.std.c++
  4. Subject: Re: Is STL MT-Safe?
  5. Followup-To: comp.programming.threads,comp.std.c++
  6. Date: 19 Apr 1996 15:31:11 PDT
  7. Organization: University of California, Riverside
  8. Approved: austern@isolde.mti.sgi.com
  9. Message-ID: <4l8pud$3t8@galaxy.ucr.edu>
  10. References: <4kmjvj$89t@usc.edu> <4kspmb$9tb@ubszh.fh.zh.ubs.com> <3173E95E.5AC@ix.netcom.com> <4l12rf$q11@galaxy.ucr.edu> <31753C02.58A6@ix.netcom.com>
  11. NNTP-Posting-Host: isolde.mti.sgi.com
  12. X-Original-Date: 19 Apr 1996 19:35:41 GMT
  13. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBVAwUBMXgUMEy4NqrwXLNJAQGtUgH/aFbnAXVNwo2SgCltJlzxcItQjp4w48Wn
  16.     RgCGsvoJdHrgbvs7UNuEczbmtZ3I4Ntc1PvTpc7VAFxqS1coazkh9w==
  17.     =z2Kf
  18. Originator: austern@isolde.mti.sgi.com
  19.  
  20. David Brownell (brownell@ix.netcom.com) wrote:
  21. : Tom Payne wrote:
  22. [...]
  23. : > 
  24. : > The standards process is the appropriate forum for such vendor
  25. : > agreement.  Unfortunately, the standards bodies have failed to provide
  26. : > the necessary leadership in the areas involving concurrency and
  27. : > asynchrony.  Perhaps, these bodies simply have other fish to fry --
  28. : > getting the current standard completed is an monumental task.
  29. : 
  30. : Well, POSIX.1c happened; it's the ANSI/ISO C++ team that's said such
  31. : issues are "out of scope" for now.  I don't think it's realistic to
  32. : expect POSIX to produce a C++ binding at this time, given some of the
  33. : issues raised in my writeup above.  Nor do I think vendors should be
  34. : gratuitously diverging, even lacking a formal standards framework.
  35.  
  36. Unfortunately, competition begets for product differentiation, and
  37. vendors must compete.  Standardization is the responsibility of
  38. standards bodies, who, I realize, must separate and prioritize their
  39. concerns.  Nevertheless ...
  40. : > ... a C++ program (with defined behavior)
  41. : > cannot deal efficiently with some of the simplest asynchrony, e.g., a
  42. : > hardware-detected exception cannot generate a program exception,
  43. : > unless the program explicitly polls for it, thus, requiring
  44. : > unacceptable overhead both in running time and programming effort.
  45. : 
  46. : Some of us don't think that it's necessarily a good thing to complicate
  47. : C++ exception processing further -- it's a synchronous mechanism now.
  48. : I'd hope that the current mechanism for asynchrony (signals) would just
  49. : be fixed to address your issues!
  50.  
  51. Fixing the stantard so that signal handlers can read global data (with
  52. appropriate qualifications on the significance of the result) would be
  53. a significant help.  The complexity here is only in the wording of the
  54. standard.  
  55.  
  56. The second major need is to allow a signal to force an exception in
  57. without the program polling for it.  Complexity is never "necessarily
  58. a good thing," unless the benefits outweigh the costs.  The benefits
  59. would be
  60.  
  61.   *  lower latency exception responses to signals
  62.  
  63.   *  elimination of the CPU overhead of polling
  64.  
  65.   *  much simpler programming for such situation.
  66.  
  67. The cost would be in the increased complexity of the implementation
  68. and CPU overhead caused by the implementation.  In a thread on this
  69. topic a couple months ago, David Chase gave an implementation strategy
  70. based on range tables that seemed to involve no CPU overhead and whose
  71. complexity seemed reasonable.
  72.  
  73. Tom Payne (thp@cs.ucr.edu)
  74. ---
  75. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  76.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  77.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  78.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  79.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  80. ]
  81.